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I. REAL PARTY IN INTEREST 

WorldCom, Inc is the real party in interest. 



II. RELATED APPEALS AND INTERFERENCES 

Appellants are unaware of any related appeals and interferences. 
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III, STATUS OF THE CLAIMS 

Claims 1-3, 5-10, 12-16, 18-25, and 27-33 are pending in this appeal. No claim is 
allowed. This appeal is taken from the October 9, 2002 final rejection of all the pending claims. 

IV, STATUS OF AMENDMENTS 

A Response under 37 CFR § 1.116 was timely filed on December 9, 2002. No 
amendments were requested. An Advisory Action dated December 20, 2002 stated that no claims 
were allowed and no claims were objected to. 

V, SUMMARY OF THE INVENTION 

A description of an exemplary embodiment of the claimed invention follows. Networks, 
which are growing larger in size and more complex in nature, typically include a communication 
infrastructure of hundreds or thousands of managed devices such as routers, switches, hubs and 
concentrators from numerous vendors, which implement various technologies. In some networks, 
the managed devices are identified manually, which is susceptible to human error. In other 
networks, management stations obtain information of the managed devices. Existing managed 
devices may experience hardware updates. Also, new managed devices may be added, and 
existing managed devices may be removed. Discovery and identification of managed devices are 
increasingly difficult and time-consuming, as networks become larger and more heterogeneous to 
include thousands of individual managed devices (page 1, line 10 to page 2, line 24). 

In Fig. 1, a network 10 includes a plurality of managed devices 12 which electrically 
communicate by data packets with each other and with associated personal computers (not 
shown). Management station 14 identifies each managed device, e.g., by vendor/ manufacturer, 
model, system software version, etc. The interface of a managed device 12 is determined by the 
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vendor/ manufacturer, model and/or system software version, etc. (page 5, line 16 to page 6, line 



In Fig. 4, following the selection of one managed device 12 of network 10 at step S10, 
processor 40 of the management station 14 proceeds to step S12 and communicates by outputting 
an initial command to the selected managed device 12 to stimulate/trigger an initial response to 
uniquely identify the managed device 12. At step SI 4, processor 40 determines whether a 
response from the managed device 12 was received. If not (i.e., the response fails, e.g. the 
managed device 12 does not support the initial command), processor 40 proceeds to step S16 to 
determine whether more commands are available for application to identify the managed device 
12. If at least one new (different from the initial command) command is available, processor 40 
communicates by outputting the subsequent new command at step SI 8 to the managed device 12 
(page 10, line 1 1 to page 11, line 3). 

If a response to an applied initial or subsequent command is received, processor 40 
compares the command and received response with device type data within a device table in an 
attempt to match the command and response with a device type at steps SI 7 and SI 8. Entries 
exist for individual device types that specify the associated command ED value, the vendor 
manufacturer of the device, the model of the device, and the hardware category (e.g., router or 
switch) of the device. Such matching can either directly identify the managed device 12 or 
provide an indication that subsequent commands are needed to accurately and completely identify 
the currently polled managed device 12 (page 11, line 9 to line 23). 

If the responding managed device 12 can be* identified as a unique device, processor 40 
proceeds to step S20 to add the thus identified managed device 12 to an asset table (page 12, lines 
3-6). Thereafter, processor 40 of management station 14 proceeds to the next node and 
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corresponding address and performs the flow chart again to attempt to determine the device type 
of the next associated managed device 12. Such can occur until all nodes and associated managed 
devices are analyzed (page 13, lines 10 to 15). 

The polling of an exemplary managed device 12 is described next. Initially, management 
station 14 outputs a first identification command. If a response includes the character string" 
"%. cisco. %H 5 processor 40 utilizes the response to ascertain a that the currently polled managed 
device 12 is a Cisco® 4500 or Cisco® 7000 (page 15, lines 13 to 17). The applied management 
commands individually correspond to respective device types of the identified managed devices. 

The processor 40 issues a subsequent command for application to the managed device 12 
that just responded and was partially identified as Cisco® 4500 or Cisco® 7000 (i.e., no unique 
device was determined from the initial signature). This subsequent command indicates 
(individually corresponds to) the group of device types (Cisco® 4500 or Cisco® 7000) of the 
partially identified managed device without specifically identifying the exact model and 
manufacturer (page 17 line 1 to page 18, line 4). 



VI. ISSUES 

Whether claims 1-3, 5-10, 12-16, 18-25, and 27-33 are anticipated under 35 U.S.C. § 102 
by Kracht (US 6,377,987)? 

Whether claims 1-3, 5-10, 12-16, 18-25, and 27-33 are anticipated under 35 U.S.C. § 102 
by the Examiner's "rare finding"? 
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VII. GROUPING OF CLAIMS 

The claims should not be regarded as all standing together since the claims recite 
respective limitations that render each of the claims separately patentable. For the purposes of 
this appeal, the following groups are recognized: 

1. Claims 1-3, 5, 6, 8-10, 12, 13, 15, 16, 18, 22, 24, 25, 27, 28, 29, 31, and 32 

2. Claims 7, 14, 20, and 30 

3. Claims 15, 23, and 33 

4. Claim 19 

5. Claim 21 

VIII. ARGUMENT 

A. THE EXAMINER'S LEGAL BURDEN: 

The initial burden of establishing a prima facie basis to deny patentability to a claimed 
invention under any statutory provision always rests upon the Examiner. In re Mayne, 41 
USPQ2d 1451 (Fed .Cir. 1997); In re Deuel, 34 USPQ2d 1210 (Fed. Cir. 1995); In re Bell, 26 
USPQ2d 1529 (Fed. Cir. 1993); In re Oetiker, 24 USPQ2d 1443 (Fed. Cir. 1992). 

To anticipate a patent claim under 35 U.S.C. § 102, every element and limitation of the 
claimed invention must be found in a single prior art reference, arranged as in the claim. Karsten 
Mfg. Corp. v. Cleveland Golf Co., 242 F.3d 1376, 1383, 58 USPQ2d 1286, 1291 (Fed. Cir. 
2001); Scripps Clinic & Research Foundation v. Genentech, Inc., 927 F.2d 1565, 1576, 18 
USPQ2d 1001, 1010 (Fed. Cir. 1991). 
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A prior art reference anticipates a patent claim if it discloses every limitation of the 
claimed invention, either explicitly or inherently. In re Schreiber, 128 F.3d 1473, 1477, 44 
USPQ2d 1429, 1431 (Fed. Cir. 1997). "Under the principles of inherency, if the prior art 
necessarily functions in accordance with, or includes, the claimed limitations, it anticipates." 
MEHL/Biophile Int'l Corp. v. Milgraum, 192 F.3d 1362, 1365, 52 USPQ2d 1303, 1305 (Fed. Cir. 
1999). 

The rejection of claims 1-3, 5-10, 12-16, 18-25, and 27-33 must be reversed, because 
Kracht does not disclose the limitations of the claims. 



B. CLAIMS 1-3, 5, 6, 8-10, 12, 13, 15, 16, 18, 22, 24, 25, 27, 28, 29, 31, AND 32 
ARE NOT ANTICIPATED OVER KRACHT, BECAUSE KRACHT FAILS TO 
DISCLOSE TRANSMITTING SUBSEQUENT COMMANDS THAT ARE 
DIFFERENT FROM THE PRIOR COMMANDS. 

The rejections of claims must be reversed, because Kracht does not disclose the limitations 
of the claims, and features not disclosed in Kracht may not be provided with the Examiner's 
hindsight conjectures. 

For example, independent claim 1 recites the following feature: 

transmitting subsequent commands that are different from the prior 
commands* 

Independent claim 8 recites the following feature: 

the management station selectively outputs a second command from the 
plurality of commands to the managed device if the first command does 
not provide unique identification of the managed device, the second 
command being different from the first command. 

Independent claim 15 recites the following feature: 

computer usable program code configured to cause the management station to 
transmit subsequent commands from the set of commands to the 
responding ones of the managed devices if the identities are not 
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determined, wherein the subsequent commands are different from the 
initial commands. 

Independent claim 22 recites the following feature: 

selectively outputting subsequent commands to the managed devices based on 
the determining step, wherein the subsequent commands are different 
from the initial commands. 

Independent claim 31 recites the following feature: 

selectively issuing another one of the plurality of commands based on the 
determining step, the other command being different from the one 
command. 

The above feature is also recited implicitly by their dependency correspondingly in claims 2, 
3, 5, 6, 7, 9, 10, 12-14, 16, 18-21, 23-35, 27, 28-30, 32, and 33. 

By contrast, the Kracht system is configured to infer or guess at identify of responding 
ones of the managed devices by only analyzing information already available. In particular, 
Kracht discloses, on col. 8, lines 1-27, that when a device type cannot be identified, an additional 
attempt is made to determine the type of device. For example, the prefix of the sysObjectID 
variable may be used to determine whether the device is a "Cisco" device. If so, then the 
discovery mechanism uses the MIB sysServices value to identify the service layers at which the 
device operates; this enables the discovery mechanism to make an educated guess of the device 
type. 

For example, based on the service layer at which a device operates, the discovery 
mechanism may identify a device as a "generic" hub, router or switch. The sysServices value 
generally includes a bit vector having one bit associated with each layer of services in the seven- 
layer OSI networking model. Each layer in the OSI model, and therefore each bit, represents a 
service layer at which a device may potentially operate. Because different device types operate at 
different layers, by determining what bits are set in the bit vector, the discovery mechanism can 
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make an educated guess as to the device type. FIG. 3 illustrates a bit vector 300 that includes one 
or more bits 302, 304, 306 which respectively correspond to service layers "3", "2" and "1". The 
value of each bit 302, 304, 306 indicates whether the device may operate at the corresponding 
layer. The discovery mechanism may also guess a device type based on information that indicates 
the highest service level at which a device can physically operate. Table 1 is an example of such 
information. 

It is evident that the Kracht system operates to improve the partial identity of devices 
NOT by transmitting or outputting a second command, but bases a second attempt at 
identification of the device on the received sysObjectID using its prefix, the MIB sysServices 
value to identify the service layers, and the bit vector 300 (see FIG. 3). This Kracht second 
attempt at identification does not entail issuance of a second (or subsequent) command. 

The missing claimed elements have not been alleged by the Examiner to be inherent or 
implied by Kracht. The Kracht system issues only one to try to identify a device in a network, 
and if that fails, Kracht does not issue a subsequent command to the same device in a further 
attempt at identification. 

If no reply is received after sending the SNMP request, the thread continues to the next 
address that it has been assigned to determine whether it is potentially associated with a device 
{Kracht, column 7, lines 47 - 50). 

Therefore, Kracht is a good example of the management problems identified and analyzed 
as set forth in the above SUMMARY OF THE INVENTION. 

Because Kracht fails to teach or otherwise suggest "transmitting subsequent commands 
that are different from the prior commands," the rejection of claims 1-3, 5-10, 12-16, 18-25, 
and 27-33 as anticipated by Kracht is improper and should be reversed by the Honorable Board. 
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Moreover, the claimed elements cannot be considered obvious over Kracht. In re 

Sponnoble (CCPA, 1969), 160 USPQ 237 stated: 

It should not be necessary for this court to point out that a patentable invention may lie in 
the discovery of the source of a problem even though the remedy may be obvious once the 
source of the problem is identified. This is part of the 'subject matter as a whole' which 
should always be considered in determining the obviousness of an invention under 35 



Specifically, Kracht discloses the following problem: "In the past, constructing a network 
topology using automatic methods or means has been awkward or produces incomplete or 
inaccurate information" (Kracht, column 1, lines 61 - 63). Kracht also discloses: "However, a 
drawback with this approach is that certain devices may not support the discovery protocol" 
(column 2, lines 64, 65). 

Under the Kracht heading of "3. IDENTIFYING ADDRESSES THAT ARE 
ASSOCIATED WITH DEVICES" (Kracht, column 7, lines 1 and 2), a Kracht "thread may 
'ping 5 each address it has been assigned. If no response is received to the 'ping', the thread 
continues to the next address" (Kracht, column 7, lines 20 - 22). A "ping" is the sending of an 
Echo Request Packet to an address so that an active device at that address will return an Echo 
Reply Packet (Newton 's Telecom Dictionary by Harry Newton, 2001 edition). 

The Kracht "ping" is to find out if the node of a particular address is active, not to serve 

any device ID (identification) function. A management station cannot use the echo in a ping to 

identify any device. Thus, Kracht starts to identify a device type after a "ping" or the like has 

found an address where a device may be found. In Kracht, the initial identifying command 

results in a response having a sysObjectID that: 

"may identify a device by name, type, or model number ... the returned sysObjectID 
variable is compared to a set of known sysObjectID values in an attempt to identify the 
particular device type. (Kracht, column 7, lines 54-61) 
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Both Kracht and the present invention recognize that a problem of identification may still 



"In certain embodiments, when a device type cannot be identified, an additional 
attempt is made to determine the type of device." {Kracht, column 8, lines 1 - 3) 

It is at this point that Kracht and the present claimed invention diverge. The Examiner 

has employed hindsight in interpreting the "additional attempt" of Kracht as meaning the 

management station issues a subsequent command based on the response and the further attempt 

at device type identification is based upon the response to the subsequent command. This is not 



In re Sponnoble (CCPA, 1969), 160 USPQ 237 further stated: 

"The court must be ever alert not to read obviousness into an invention on the basis of the 
applicant's own statements; that is, we must view the prior art without reading into that 
art appellant's teachings. ... The issue then is whether the teachings of the prior art would, 
in and of themselves and without the benefits of appellant 's disclosure, make the 
invention as a whole, obvious." 

The Kracht approaches to the above-stated problems are quite different than those of the 
claimed invention. 

The first Kracht approach is performed with no subsequent command and response, but 

only by analyzing information existing after the initial command and response, to make an 

inference of identity but not a unique or accurate ID within the meaning of the present invention: 

According to yet another feature, the method involves determining service layers for 
which the device operates when the device is not of a known device type; and based on 
the service layers that are determined, inferring that the device is of a particular device 
type associated with the service layers." {Kracht, column 4, lines 41-46) "the discovery 
mechanism uses the MIB sysServices value" (the above-mentioned sysObjectE) from the 
response) "to identify the service layers at which the device operates,: this enables the 
discovery mechanism to make an educated guess of the device type. For example, based 
on the service layer at which a device operates, the discovery mechanism may identify a 
device as a 'generic' hub, router or switch. {Kracht, column 8, lines 5-11) 



exist: 



the case. 



10 



•^V/ * 09/329,209 




• 



Patent 



The second Kracht approach is performed with no subsequent command and response, 
but only by analyzing information existing after the initial command and response, to make a 
guess of identity but not a unique or accurate ID within the meaning of the present invention: 

"The sysServices value generally includes a bit vector that having one bit associated with 
each layer of services in the seven-layer OSI networking model. . . . Because different 
device types operate at different layers, by determining what bits are set in the bit vector, 
the discovery mechanism can make an educated guess as to the device type." {Kracht, 
column 8 5 lines 12 - 19) "However, if bit 302 is not set, the discovery mechanism next 
determines whether bit 304 is set. If so, then the discovery mechanism identifies the 
device as a switch. If both bit 302 and bit 304 are not set, the discovery mechanism 
determines whether bit 306 is set. If so, then the discovery mechanism identifies the 
device as a hub. {Kracht, column 8, lines 42 - 49) 

The third Kracht approach is performed with no subsequent command and response, but 
only by analyzing information existing after the initial command and response, to make a 
determination of identity but not a unique or accurate ID within the meaning of the present 



an unidentifiable device ("black cloud device") is associated with an address within the 
set of network addresses but which was not identified as a known device. The discovery 
mechanism knows a black cloud device is present in the network, but cannot determine 
what it is. {Kracht, column 12, lines 59 - 64) ". . . the discovery mechanism may use the 
collected configuration information to infer the location of black cloud devices with the 
network topology." {Kracht, column 13, lines 1-3) "because multiple devices cannot be 
linked to a single port, the discovery mechanism infers that known devices 602, 604, 606 
are physically linked to a black cloud device 608 and not to each other" {Kracht, column 
13, lines 22 - 26) "Thus, by identifying ports of known devices that do not appear to be 
linked to another discovered device, based on that device's CDP information, the 
discovery mechanism can resolve whether the ports are physically linked to a black cloud 
device, by determining whether more than one MAC address, which are not associated 
with discovered devices, are observed at each of the ports" {Kracht, column 13, lines 52 - 
58) "At block 914, black cloud devices are identified. As previously indicate, by 
observing what MAC addresses are observed by each port of the known devices, the 
process can identify physical links that are made to groups of one or more unknown 
devices.: {Kracht, column 17, lines 10-14)) 

It is Appellants who redefined the problem of a heterogeneous network occasionally 
creating a failed response when a device is in fact at the node address. Appellants' analysis found 
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a cause of a failure of identification is that a failed response may apply to more than one unique 
device due to the heterogeneous nature of networks. Appellant's solution is not to analyze 
available information to guess or imply, as in Kracht, but rather to apply one or more subsequent 
commands to the same device, which subsequent commands are based on the failed response. 
The Appellant's description of an embodiment is a response failing in that it identified more than 
one type of device, namely Cisco® 4500 or Cisco® 7000, and therefore the subsequent command 
includes data that would distinguish between a Cisco® 4500 device and a Cisco® 7000 device to 
obtain a unique identification. 

In re Sponnoble (CCPA, 1969), 160 USPQ 237, as in many other cases, the court stated: 
"references themselves teach away" from the claimed invention. All of the Kracht solutions are 
performed with no subsequent command or response after the initial ones. Kracht teaches that the 
second attempt at identity is done only with information existing after the initial command and 
response. In support of the rejection, the Final Rejection, on page 1, item 2, asserts that Kracht 
(column 7, line 56) teaches a second command. Appellants respectfully disagree with this 
assertion, in that Kracht merely describes a second attempt to determine the type of device using 
information already received from the first SNMP request, notably the sysObjectlD. Kracht has 
no second or subsequent command issued in an attempt at a device ID and in fact teaches away 
from the present invention. 

Therefore, even if the Examiner were to change the basis of rejection to one of 
obviousness, such a rejection would be unsustainable. 
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C. CLAIMS 7, 14, 20, AND 30 ARE NOT ANTICIPATED OVER KRACHT, 
BECAUSE KRACHT FAILS TO DISCLOSE THE APPLIED 
MANAGEMENT COMMANDS INDIVIDUALLY CORRESPOND TO 
RESPECTIVE DEVICE TYPES OF THE IDENTIFIED MANAGED 
DEVICES. 



The rejection of claims 7, 14, 20, and 30 should be reversed because Kracht fails to teach or 

suggest the features of the claims. For example, claim 7 recites the following feature: 

wherein the management station is configured to apply management 
commands to respective identified managed devices, the applied 
management commands individually correspond to respective device 
types of the identified managed devices. 

Claim 14 recites the following feature: 

wherein the management station is configured to apply a management 
command to an identified managed device, the applied management 
command individually corresponds to a device type of the identified 
managed device. 

Claim 20 recites the following feature: 

computer usable program code configured to cause the management station to 
apply a plurality of management commands to respective identified 
managed devices, the applied management commands individually 
correspond to respective device types of the identified managed 
devices. 

Claim 30 recites the following feature: 

applying a plurality of management commands to the identified managed 
devices individually corresponding to respective device types of the 
identified managed devices. 

With respect to claim 14, the Final Office Action, on page 2, item 7, refers generally to 

the use of MBs, citing col. 7, lines 35- et seq. 9 which, in pertinent part, states: 

In one embodiment, the information requested by a thread includes 
Management Information Base ("MB") information about the particular device. 
For example, the information requested by a thread may include the MB variable 
sysObjectED. The MB variable sysObjectE) identifies the particular type of 
device that is associated with the network address. A description of SNMP, MBs 
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and the type of MIB information that may supported by a device is described in 
Downes et al. 5 "Internetworking Technologies Handbook" (Indianapolis, Ind.: 
Macmillan Technical Publishing, 1998), Chapter 52. 

The above passage merely discloses that a thread includes MIB information about the 
particular device, such as the MIB variable sysObjectID, not that "the applied management 
commands individually correspond to respective device types of the identified managed 
devices," as claimed. 

As mentioned under the SUMMARY OF THE INVENTION, in this brief, the processor 
40 issues a subsequent command for application to the managed device 12 that just responded 
and was partially identified as Cisco® 4500 or Cisco® 7000 (i.e., no unique device was 
determined from the initial response). This subsequent command (individually corresponds to the 
group of device types (Cisco® 4500 and Cisco® 7000) of the partially identified managed device 
without specifically identifying the exact model and manufacturer (page 17 line 1 to page 18, line 
4). The response to this subsequent command would narrow down which of the group is the 
device. 

Because Kracht fails to teach or otherwise suggest "the applied management commands 
individually correspond to respective device types of the identified managed devices," the 

rejection of claims 7, 14, 20, and 30 as anticipated by Kracht is improper and should be reversed by 
the Honorable Board. 

D. CLAIMS 15, 23, AND 33 ARE NOT ANTICIPATED OVER KRACHT, 
BECAUSE KRACHT FAILS TO DISCLOSE AN ASSET TABLE 
CONTAINING THE IDENTIFIED MANAGED DEVICES. 

The rejection of claims 15, 23, and 33 should be reversed because Kracht fails to teach or 
suggest the features of the claims. For example, claim 15 recites the following feature: 
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computer usable program code configured to cause the management station to 
provide an asset table containing the identified managed devices. 

Claim 23 recites the following feature: 

providing identified managed devices within an asset table. 

Claim 33 recites the following feature: 

storing the device type information in an asset table based on the determined 
device type information. 

The above feature is also recited implicitly by its dependency in claim 1 8. 

For the rejection of the above claims, the Final Office Action, on page 2, item 9, 
conveniently states: "Per the other claims not specifically mentioned, they too are rejected for the 
reasons outline above." The "reasons outline above" (ostensibly, the rationale with respect to 
claim 8 on page 1, item 4) provides no information on the claimed asset table. Such an 
uninformative rejection is in direct contravention of 35 U.S.C. § 132, which requires the Director 
to "notify the applicant thereof, stating the reasons for such rejection." This section is violated if 
the rejection "is so uninformative that it prevents the applicant from recognizing and seeking to 
counter the grounds for rejection." Chester v. Miller, 15 USPQ2d 1333 (Fed. Cir. 1990). MPEP 
§ 706 states that "[t]he goal of examination is to clearly articulate any rejection early in the 
prosecution process so that applicant has the opportunity to provide evidence of patentability and 
otherwise respond completely at the earliest opportunity." Furthermore, MPEP § 706.02(j) 
indicates that: "[i]t is important for an examiner to properly communicate the basis for a rejection 
so that the issues can be identified early and the applicant can be given fair opportunity to 
respond." 

Because Kracht fails to teach or otherwise suggest "an asset table," the rejection of claims 
15, 23, and 33 as anticipated by Kracht is improper and should be reversed by the Honorable Board. 
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E. CLAIM 19 IS NOT ANTICIPATED OVER KRACHT, BECAUSE KRACHT 
FAILS TO DISCLOSE COMPUTER USABLE DATA INCLUDING A 
STATE TRANSITION TABLE INCLUDING A PLURALITY OF 
IDENTIFIERS. 

The rejection of claim 19 should be reversed because Kracht fails to teach or suggest the 

features of the claims. For example, claim 19 recites the following feature: 

computer usable data including a state transition table including a plurality 
of identifiers. 

As regards claim 19, the Final Office Action, on page 2, item 9, relies on the omnibus 
assertion that "Per the other claims not specifically mentioned, they too are rejected for the 
reasons outline above." Given what Kracht does disclose, Applicants are at loss at how Kracht 
can be reasonably applied for disclosure of the claimed state transition table. Again, the rejection 
of claim 19 runs a fowl 35 U.S.C. § 132. 

Because Kracht fails to teach or otherwise suggest "computer usable data including a state 
transition table including a plurality of identifiers," the rejection of claim 19 as anticipated by 
Kracht is improper and should be reversed by the Honorable Board. 

F. CLAIM 21 IS NOT ANTICIPATED OVER KRACHT, BECAUSE KRACHT 
FAILS TO DISCLOSE A NODE TABLE COMPRISING A PLURALITY 
OF NODE LOCATIONS FOR RESPECTIVE MANAGED DEVICES. 

The rejection of claim 21 should be reversed because Kracht fails to teach or suggest the 

features of the claims. For example, claim 21 recites the following feature: 

a node table comprising a plurality of node locations for respective 
managed devices. 

As with claim 19, the Final Office Action, on page 2, item 9, rejects claim 21 by lumping 
the claimed features under the generic rejection: "Per the other claims not specifically mentioned, 
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they too are rejected for the reasons outline above." The Kracht system does not disclose any use 
of the claimed node table. The Examiner has left Applicant to rely on conjecture for the basis for 
rejection, thereby implicating 35 U.S.C. § 132. 

Because Kracht fails to teach or otherwise suggest "a node table comprising a plurality 
of node locations for respective managed devices," the rejection of claim 21 as anticipated by 
Kracht is improper and should be reversed by the Honorable Board. 

G. CLAIMS 1-3, 5-10, 12-16, 18-25, AND 27-33 ARE NOT ANTICIPATED 
UNDER 35 U.S.C. S 102 BY THE EXAMINER'S "RARE FINDING." 

The Final Office Action, on page 2, item 9, makes a last effort to reject the claimed 

invention by providing the following tenuous statement: 

The Examiner makes this rare finding that the claims are directed to well 
known discovery methods for probing devices. That is, a first communication 
protocol is used to communicate with the device, and if the device fails to 
respond, subsequent protocols are used until either the device responds or all 
known protocols have failed. This is very much akin to asking a person for his/her 
name in one language, if the person just stands there bewildered, asking in 
different languages or forms of communications may provide a result. 

First Sentence Of The Above Quotation: The Administrative Procedures Act (APA) 

mandates the Patent Office to make the necessary findings and provide an administrative record 

showing the evidence on which the findings are based, accompanied by the reasoning in reaching 

its conclusions. See In re Zurko, 258 F.3d 1379, 1386, 59 USPQ2d 1693, 1697 (Fed. Cir. 2001); 

In re Gartside, 203 F.3d 1305, 1314, 53 USPQ2d 1769, 1774 (Fed. Cir. 2000). In particular, the 

Patent Office must articulate and place on the record the "common knowledge" (here the "well 

known discovery methods") used to negate patentability. In re Zurko, id. ; In re Sang Su Lee, No. 

00-1 158 (Fed. Cir., Jan. 18, 2002). 
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Second Sentence Of The Above Quotation: The Examiner is paraphrasing a portion of 
Applicants' claims, not providing a record of the "common knowledge" relied upon in the Final 
Rejection. 

Third and Last Sentence Of The Above Quotation: Applicants do not understand this 
statement, as it makes light of Applicants' contribution to the networking art. The inventors were 
faced with networking art that was replete with proprietary and incompatible protocols. The 
inventors solved the problem. The solution was not "common knowledge" in the networking art 
at the time of the invention, which is evidenced by the Examiner's lack of any source or 
reference. The Examiner's analogy, "akin to", comes from hindsight. The Examiner's imagined 
alleged analogous human conversation is not an anticipation of Applicants' claimed computer 
performed networking invention. 

A computer is not a human. The computer sends a command to a node address, not 
knowing if a device is at the node; whereas, in the Examiner's analogy, the human sees another 
human and is not talking to every location where a human may of may not be located. The 
computer in Kracht is programmed to move to the next location, whereas the Examiner's human 
sees there is a human at the first location. The subsequent command of the Appellants' computer 
is based on the understood information of the failed command (e.g., the failed command tells the 
computer that the device is a Cisco® 4500 or Cisco® 7000); whereas any subsequent speech 
from the Examiner's human is based on what is seen and the fact that the response was not 



In re Sponnoble (CCPA, 1969), 160 USPQ 237 stated: 

"The court must be ever alert not to read obviousness into an invention on the basis of the 
applicant's own statements; that is, we must view the prior art without reading into that 
art appellant's teachings. ... The issue then is whether the teachings of the prior art would, 
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in and of themselves and without the benefits of appellant 's disclosure, make the 
invention as a whole, obvious." 

The fact situation and finding of In re Zurko ( (CAFC; 96-1258; 1997), 42 USPQ2nd 
1476, reversed on issues not important here in Dickinson v. Zurko, (Supreme Court, 1999), 119 
S.Ct. 1816) is thought to be relevant to the present appeal. Zurko claimed sending a user 
command over an untrusted pathway to an untrusted computer environment (UTE), the UTE sent 
the command to a trusted computer environment (TCE), the TCE repeated the command over a 
trusted pathway to the user, the user confirmed over a trusted pathway to the TCE, and the TCE 
executed the now trusted command. PTO position in Zurko: All claims were rejected under 35 
USC 103, stating that the only step not taught explicitly in the prior art (the confirmation over a 
trusted path) is inherent or implicit in the prior art, because there are only two ways the it may be 
accomplished, over an untrusted or trusted pathway. It is basic knowledge that communication in 
a TCE is over a trusted pathway. One wanting to create a secure environment would know to 
request confirmation over a trusted pathway. The motivation to combine the references comes 
from the nature of the problem to be solved. The court's finding: To imbue one of ordinary skill 
in the art with knowledge of the invention in suit, when no prior art reference conveys or suggests 
that knowledge, is to fall victim to the insidious effect of a hindsight syndrome wherein that 
which only the inventor taught is used against its teacher. The Board impermissibly used 
hindsight to arrive at the claimed invention. While in retrospect, looking at applicants 5 invention, 
it might seem logical to perform a repeat-back over a trusted line, neither cited reference teaches 
it. Finally, to say that the missing step comes from the nature of the problem to be solved (here 
implied from the present Examiner's analogy) begs the question because the Board failed to show 
that this problem had been previously identified anywhere in the prior art. In re Sponnoble: 
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"patentable invention may lie in the discovery of the source of a problem even though the remedy 
may be obvious once the source of the problem is identified." 

Moreover, the analogy presented reveals an apparent lack of appreciation for the 
imaginary person who is capable of asking the bewildered person in multiple languages, and such 
a multilingual person is a "rare finding." 

The "rare finding" or "common knowledge" rejection under 35 U.S.C. § 102 should be 
reversed as: having an insufficient record; being based on hindsight; not meeting all of the 
claimed limitations relating to being computer implemented in a networking environment; and 
using the inventors contribution of identifying and analyzing the prior art problems as reasons for 
rejection rather than properly looking at them as part of the invention. 

IX. CONCLUSION AND PRAYER FOR RELIEF 

In view of the arguments proffered, Appellants contend that the anticipation rejections 
cannot be sustained, as 35 U.S.C. § 102 requires that each and every element of the claim be 
disclosed in a prior art reference. The reference to Kracht does not anticipate the claimed 
invention. Further, the "rare finding" made by the Examiner does not anticipate the claimed 
invention. 
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Appellants, therefore, request the Honorable Board to reverse each of the Examiner's 



rejections. 
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APPENDIX 



1. A network apparatus comprising: 

a management station configured to output a plurality of commands to a plurality of 
managed devices for stimulating responses from the managed devices, 

wherein the management station is configured to identify responding ones of the managed 
devices by selectively transmitting subsequent commands that are different from the prior 
commands. 

2. The apparatus according to claim 1 wherein the management station is configured to 
execute a Simple Network Management Protocol management program. 

3. The apparatus according to claim 1 wherein the management station is configured to 
communicate with the managed devices using Transmission Control Protocol/Internet Protocol 
communications. 

5. The apparatus according to claim 1 wherein the received responses comprise failed 
responses. 

6. The apparatus according to claim 1 wherein the management station is configured to 
compare individual received responses with a device table to identify the device types of 
responding one of the managed devices. 

7. The apparatus according to claim 6 wherein the management station is configured to 
apply management commands to respective identified managed devices, the applied management 
commands individually correspond to respective device types of the identified managed devices. 

8. A network comprising: 

a management station configured to output a first command from a plurality of commands 
to a managed device to identify the managed device, wherein the management station selectively 
outputs a second command from the plurality of commands to the managed device if the first 
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command does not provide unique identification of the managed device, the second command 
being different from the first command. 

9. The network according to claim 8 wherein the management station and the managed 
device are individually configured to execute a Simple Network Management Protocol program. 

10. The network according to claim 8 wherein the management station is configured to 
communicate with the management device using Transmission Control Protocol/Internet 
Protocol. 

12. The network according to claim 8 wherein a received response associated with the 
first command comprises a failed response. 

13. The network according to claim 8 wherein the management station is configured to 
compare a response from the managed device with a device table to identify device type. 

14. The network according to claim 8 wherein the management station is configured to 
apply a management command to an identified managed device, the applied management 
command individually corresponds to a device type of the identified managed device. 

15. A computer program product comprising: 

computer usable program code configured to cause a management station to communicate 
a plurality of initial commands to a plurality of managed devices of a network; 

computer usable program code configured to cause the management station to identify the 
managed devices based upon a plurality of initial responses from the managed devices; 

computer usable program code configured to cause the management station to transmit 
subsequent commands to the responding ones of the managed devices if the identities are not 
determined, wherein the subsequent commands are different from the initial commands; and 

computer usable program code configured to cause the management station to provide an 
asset table containing the identified managed devices. 
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16. The product according to claim 15 further comprising computer usable data 
comprising a device table corresponding to the managed devices. 

18. The product according to claim 15 wherein the received initial responses comprise 
failed responses. 

19. The product according to claim 15 further comprising: computer usable data including 
a state transition table including a plurality of identifiers; and 

computer usable program code configured to cause the management station to compare 
the received initial responses with the identifiers to identify the device types of the respective 
responding managed devices. 

20. The product according to claim 15 further comprising computer usable program code 
configured to cause the management station to apply a plurality of management commands to 
respective identified managed devices, the applied management commands individually 
correspond to respective device types of the identified managed devices. 

21. The product according to claim 15 further comprising computer usable data including 
a node table comprising a plurality of node locations for respective managed devices. 

22. A management station operational method comprising: 

outputting a plurality of initial commands to managed devices using a management station 

to stimulate initial responses from the managed devices; 

determining identities of the managed devices based on received initial responses; and 
selectively outputting subsequent commands to the managed devices based on the 

determining step, wherein the subsequent commands are different from the initial commands. 

23. The method according to claim 22 further comprising providing identified managed 
devices within an asset table. 
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24. The method according to claim 22 further comprising executing Simple Network 
Management Protocol management programs using the managed devices and the management 
station. 

25. The method according to claim 22 wherein the outputting and receiving individually 
comprise outputting and receiving using Transmission Control Protocol/Internet Protocol 
communications. 

27. The method according to claim 22 wherein the initial responses comprising failed 
responses. 

28. The method according to claim 22 wherein the identifying comprises comparing the 
received initial responses with a device table to identify the device types of responding ones of 
the managed devices. 

29. The method according to claim 28 further comprising updating the device table after 
the receiving. 

30. The method according to claim 22 wherein the identifying comprises identifying the 
device types of the managed devices, and further comprising applying a plurality of management 
commands to the identified managed devices individually corresponding to respective device 
types of the identified managed devices. 

31. A method for discovering managed devices, the method comprising: 

selecting one of a plurality of commands for transmission to one of the managed devices 
to trigger a response unique to the one managed device; 

determining whether a combination of the one command and an associated response from 
the one managed device uniquely identifies the one managed device; and 

selectively issuing another one of the plurality of commands based on the determining 
step, the other command being different from the one command. 
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32. A method according to claim 31, further comprising: 

performing a look-up in a device table to determine device type information associated 
with the one managed device. 

33. A method according to claim 32, further comprising: 

storing the device type information in an asset table based on the determined device type 
information. 
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